Projet 11 - "Première version d'un moteur web PKM"

Nouvelle #iteration du Projet 11 - "Première version d'un moteur web PKM".

J'ai traité les tâches décrites dans ma dernière note.

• Comme me l'a signalé à plusieurs reprises Alexandre, je dois améliorer le rendu responsive sur smartphone. Jusqu'à présent, je n'ai pas encore consacré de temps à ce sujet.
• Je dois améliorer le script d'import des données dans Elasticsearch. Pour le moment, ici, je commence par supprimer toutes les données avant d'effectuer l'importation des données.
  Problème : les pages ne sont plus accessibles pendant l'exécution de ce script.

J'ai enfin publié sklein-pkm-engine sur https://notes.sklein.xyz.

En mars 2024, j'écrivais :

Pour le moment, j'utilise Obsidian Quartz pour déployer https://notes.sklein.xyz.

Est-ce que j'en suis satisfait ? Pour le moment, la réponse est non, parce que je ne le maitrise pas assez.

J'ai une grande envie d'implémenter une version personnelle basée sur SvelteKit et Apache Age, mais j'essaie de ne pas tomber dans ce Yak!.

Début mai 2024, je suis tombé dans ce Yak!, j'y ai consacré 93 heures en tout, soit l'équivalent d'environ 15 jours de travail étalés sur 8 semaines.

J'ai enfin supprimé Obsidian Quartz

J'ai changé plusieurs fois de direction :

• j'ai exploré une implémentation basée sur Apache Age,
• ensuite pg_search,
• ensuite Typesense
• et pour finir, j'ai opté pour une implémentation basée sur Elasticsearch (voir détail dans Projet 13).

Je viens d'essayer de réaliser un screencast de présentation de la version actuelle de sklein-pkm-engine, mais le résultat de mon discours était vraiment trop déstructuré pour être publié. J'essaierai de publier un screencast prochainement.

Je viens de tenter de réaliser un screencast pour présenter la version actuelle de sklein-pkm-engine, mais mon discours était trop désorganisé pour être publié. Je souhaite enregistrer une nouvelle version prochainement.

Prochains objectifs concernant le projet sklein-pkm-engine :

• Traiter les dernières tâches que j'avais listées dans Projet 11 - "Première version d'un moteur web PKM" ;
• Dresser une liste des corrections de bug et des améliorations que je souhaite apporter à notes.sklein.xyz.

Nouvelle #iteration du Projet 11 - "Première version d'un moteur web PKM".

Dans ma dernière itération du 31 août 2024, j'écrivais ceci :

Voici quelque erreur d'User Interface que je souhaite corriger.

Sur ce screenshot, les notes actuellement séparé par des <hr /> ne sont pas facilement identifiable.

Depuis, j'ai travaillé dans la branche experimentation-ui et pour le moment, j'ai le résultat suivant :

Je pense que les délimitations des notes sont maintenant mieux identifiables.

Problème User Interface que j'ai identifié : je pense que la présence d'un lien sur le titre de la note n'est pas facilement "découvrable".

Mon objectif est toujours le suivant :

Maintenant mon objectif est d'apporter le minimum de petite amélioration me permettant de remplacer l'instance notes.sklein.xyz propulsé actuellement par Obsidian Quartz par une version propulsé par sklein-pkm-engine.

-- from

Voici la liste des choses que je dois implémenter pour atteindre cet objectif.

• Comme me l'a signalé à plusieurs reprises Alexandre, je dois améliorer le rendu responsive sur smartphone. Jusqu'à présent, je n'ai pas encore consacré de temps à ce sujet.
• Je dois améliorer le script d'import des données dans Elasticsearch. Pour le moment, ici, je commence par supprimer toutes les données avant d'effectuer l'importation des données.
  Problème : les pages ne sont plus accessibles pendant l'exécution de ce script.

Je pense qu'après avoir traité ces deux tâches, je pourrais abandonner Obsidian Quartz et seulement ensuite implémenter toutes les idées pour améliorer mon Personal knowledge management "viewer".

Voici les nouveautés depuis ma dernière itération du Projet 11 - "Première version d'un moteur web PKM".

Ce commit contient le résultat du travail du Projet 13, c'est-à-dire le refactoring de PostgreSQL vers Elasticsearch ainsi que la page /src/routes/search qui permet à la fois d'effectuer une recherche sur le contenu des notes et un filtrage de type and sur les tags.

Une démo est visible ici https://notes.develop.sklein.xyz/

Ma Developer eXperience avec Elasticsearch est excellente. J'ai trouvé toutes les fonctionnalités dont j'avais besoin.

Je pense que mon utilisation des Fleeting Note n'est pas la bonne. Je pense que les notes que je qualifie de Fleeting Note sont en réalité des Diary notes ou Journal notes.

J'ai donc décidé de :

• [x] Renommer partout fleeting_note en journal_notes

Après implémentation, j'ai réalisé que j'ai fait l'erreur de mélanger l'implémentation de le page qui affiche la liste des notes antéchronologiques et la page de recherche.

Pour être efficace, le résultat de la page recherche doit être affiché en fonction du scoring de la recherche, alors que les pages listes de notes par date de publication.

J'ai donc décidé de :

• [x] Implémenter une page /diaries/ (pour la cohérence des path en anglais, je préfère "diaries" à "journaux") qui affiche une liste de notes de type Diary notes ;
  • [x] Cette page doit permettre un filtrage par tags
• [x] Implémenter une page /notes/ qui affiche une liste des notes qui ne sont pas de type Diary notes, comme des Evergreen Note, Hub note…
  • [x] Contrairement à la page liste des Diary notes, cette page de liste ne doit pas afficher le contenu des notes, mais seulement le titre des notes ;
  • [x] Je propose de classer ces titres de notes par ordre alphabétique ;
  • [x] Je propose aussi de séparer ces notes par lettre, A, B… c'est-à-dire un index alphabétique.
  • [x] Cette page doit permettre un filtrage par tags
• [x] Refactoring la page /search/ pour ordonner le résultat de la recherche par scoring.
  • [x] Cette page doit afficher le contenu des notes avec highligthing ;
  • [x] Cette page doit permettre un filtrage sur les types de notes, pour le moment Diary notes et Evergreen Note.
  • [x] Cette page doit permettre un filtrage par tags

Au moment où j'écris ces lignes, je ne sais pas encore comment je vais gérer les opérateurs or, (.

Pour le moment, le filtrage multi tags est effectué avec des and.

#iteration Projet 11 - "Première version d'un moteur web PKM".

Le nombre de tags listé sur ce screenshot est limité par un flex-wrap: wrap + height: 2em + overflow: hidden.

Problème : j'aimerais que le bouton "Afficher plus de tags…" soit affiché directement à droite du dernier tag (ici "Svelte").

Je souhaite limiter le nombre de tags affiché non pas via du css (overflow: hidden), mais via une action Svelte.

J'aimerais pouvoir utiliser cette svelte/action comme ceci :

<ul use:ItemOverflowLimiter={{itemClass: "tag"}}>
	{#each data.tags as tag}
		<li class="tag">
			<a
				href={`/search/?tags=${tag.name}`}
				>{tag.name} ({tag.note_counts})</a>
		</li>
	{/each}
	<li>Afficher plus de tags…</li>
</ul>

1 heure plus tard, j'ai réussi à atteindre mon objectif avec ce commit.
Voici le résulat 🙂 :

Voici le code de la fonction svelte/action ItemOverflowLimiter.js :

export default function ItemOverflowLimiter(node, options) {
    let destroyAllNextItems = false;
    let itemsToDestroy = [];

    // search width of items to keep
    let widthItemsToKeep = 0;
    for (let item of node.children) {
        if (
            (options?.itemClass) &&
            (!item.classList.contains(options.itemClass))
        ) {
            widthItemsToKeep += item.clientWidth;
        }
    }

    for (let item of node.children) {
        if (destroyAllNextItems) {
            if (
                (!options?.itemClass) ||
                (item.classList.contains(options.itemClass))
            ) {
                itemsToDestroy.push(item);
            }
        } else if (
            (item.offsetTop > 0) ||
            (item.offsetLeft + item.clientWidth > (node.clientWidth - widthItemsToKeep))
        ) {
            itemsToDestroy.push(item);
            destroyAllNextItems = true;
        }
    }

    for (let item of itemsToDestroy) {
        item.remove();
    }
}

Je trouve les svelte/action très agréable à utiliser.

Nouvelle #iteration de Projet 11 - "Première version d'un moteur web PKM".

En haut de cette page, j'aimerais afficher quelques tags.

En peu de la même manière que sur ce site :

Dans cette #iteration , j'affiche tous les tags, mais la liste est trop longue.

Sur ce screenshot, seules les deux premières lignes de tags sont affichées avec un fondu transparent sur la seconde ligne.

Je ne suis pas convaincu de la pertinence du fondu transparent.
Je pense que cela attire le regard d'une manière excessif sur un élément d'UI secondaire.
Je pense qu'il est préférable d'afficher une seule ligne 🤔.

Je pense ajouter à la fin d'un tags un élément UX inspiré par :

Suite à ma note 2024-08-10_1726 en lien avec le Projet 11 - "Première version d'un moteur web PKM", #JaiDécidé de ne pas implémenter les pages /tags/{tag_name}/. À la place, je souhaite que les a href des tags point vers l'url suivante : /search/?tags=tagname.

Nouvelle #iteration du Projet 11 - "Première version d'un moteur web PKM".

Voici ce que j'ai implémenté dans la sklein-pkm-engine (lien vers la version du 28 juillet 2024, 12h00) :

• [x] Implémentation d'un script qui injecte des nanoid dans le frontmatter de toutes les notes ;
• [x] Implémentation d'un script qui injecte type: fleeting_note dans toutes les notes qui se trouvent dans le dossier /Notes éphémères/ ;
• [x] Implémentation d'un script qui injecte type: evergreen_note à toutes les notes sans type ;
• [x] Implémentation d'un script qui injecte created_at: ISO 8601 sur les Fleeting Note ;
• [x] /{note_filename}/ (sans .md) affiche une seule Fleeting Note ;
• [x] / liste de toutes les Fleeting Note de la plus récente à la plus ancienne ;
• [x] Afficher les Fleeting Note liées aux Evergreen Note en bas des Evergreen Note ;
• [x] Rendering des WikiLink ;
• [x] Rendering des #tags ;
• [x] Support des fichiers binaires (image…)

J'ai déployé cette projet sur https://notes.develop.sklein.xyz/.

Voici à quoi cela ressemble :

Prochaines itérations :

• [ ] Activer l'attribue loading="lazy" sur les images ;
• [ ] Ajouter de la pagination sur / ;
• [ ] Rendering markdown :
  • [ ] Rendering des simples liens;
  • [ ] Rendering des codes sources.
• [ ] /tags/{tag_name}/;
• [ ] Affichage des tags derrière l'heure : ;
• [ ] Permettre de remplacer les tages du type JaiDécouvert par J'ai découvert pour simplifier la lecture.

Pour la génération de nanoid du Projet 11, j'ai choisi les paramètres suivants :

const nanoid = customAlphabet('0123456789abcdefghijklmnopqrstuvwxyz', 12);

D'après les calculs effectués sur https://zelark.github.io/nano-id-cc/, à raison de 100 nouvelles notes par jour (ce qui est irréaliste), sur 352 années, le risque de doublon d'id est de 1%, ce qui est largement acceptable 😉.

Je viens de publier Projet 11 - "Première version d'un moteur web PKM".